Packet inspection systems are typically deployed at the network edges to monitor the flow of packets between a network, such as a service provider network, and a public network, such as the Internet. The systems inspect packets based on the source internet protocol (IP) address, destination IP address, ports, and protocol. Packets from source addresses that are the origin of denial of service attacks can then be dropped. Further, packets having combinations of addresses, ports, and protocols can be dropped or slowed pursuant to network security policies governing the combinations in order to ensure bandwidth is reserved for other, legitimate communications.
A newer function for packet inspection systems is Deep Packet Inspection (DPI). This involves the analysis of the payload of packets of a flow to determine the identity of the flow's associated application. Example applications include peer-2-peer networks that are sometimes used for copyright theft; packets originating from these peer-2-peer applications can dropped or slowed. Other examples include voice and video applications. These are often assigned priorities that are consistent with the policies of the network. For example, voice applications, e.g., voice over internet protocol (VOIP), are often assigned preferred transport over the network in terms of latency and possibly bandwidth since such performance is required for these types of applications.
Often these packet inspection systems must monitor the packets at very high data rates, since they are deployed on links between networks or on major links within a network. To handle these high data rates, one architecture uses a combination of two physically independent packet inspection subsystems. One of the packet inspection subsystems handles data being sent to a protected or secure network and the other packet inspection subsystem handles data being sent from the protected network to a public network, for example.
Each of these dual packet inspection subsystems monitors the state of each conversation by aggregating the information from the individual packets into flows. Flows are characterized by a flow key that is a unique combination of public or unsecure network IP address, secure network IP address, public or unsecure network TCP/UDP port, secure network TCP/UDP port and protocol.
It is important that the packet inspection subsystems be synchronized to the extent that they operate in a coherent fashion on the same flows. As new flows are detected by each of the packet inspection subsystems, entries or records are created in a flow information table. A unique flow identifier is then assigned to that new flow. In one example, when a new flow is created by one of the packet inspection subsystems, that packet inspection subsystem sends a flow-create message to the other packet inspection system. This message contains the unique flow information table identifier or number and a flow key that uniquely characterizes the flow, such as a combination of the flow's public network IP address, secure network IP address, public network TCP/UDP port, secure network TCP/UDP port, and protocol.
The two packet inspection subsystems are designed to operate in a coherent fashion such that the same flows are indentified by the same flow information table identifiers. Nevertheless, under certain circumstances, conflicts sometimes arise. One common conflict occurs when both of the packet inspection subsystems seek to create a new flow record for the same flow at effectively the same time. As a result, they both assign new flow information table identifiers to that flow and then signal the other packet inspection subsystem to create a new entry in flow record memory. The problem is that the same flow will now have two different flow information table identifiers.
In one example, the conflict is arbitrated by designating one of the packet inspection subsystems as a master (secure) and the other as a slave (unsecure). It is the slave packet inspection subsystem's responsibility to recognize the conflict and then to reassign and then store flow information to the entry with the flow information table identifier dictated by the master packet inspection subsystem.